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Sobre esta traducción 


Esta traducción al español que estás leyendo nace por el interés de aprender más cosas 
sobre software libre en general y una herramienta como Git en particular. Y para que sirva 
como difusión y herramienta de aprendizaje a la hora de trabajar con Git. 


Algunos conceptos no se traducen, ya que en español están más extendidos los términos en 
inglés originales que la traducción. 


La traducción al español se comparte bajo la misma licencia que el original. Agradecer a 
Opensource.com el permitir que realizara la traducción, compartiendo el archivo original en 
formato libre .odt. 


Si este u otro contenido de los que creo y comparto te resulta de interé. Si quieres y puedes 
puedes invitarme a una cerveza mediante Liberapay. 


Si tienes algún comentario sobre esta traducción para enviar alguna corrección, alguna 
mejora o crítica (mejor si se hace de manera constructiva) puedes enviarme un correo a 


victorhck(Amailbox.org 


Puedes consultar más contenido relacionado con GNU/Linux y software libre en mi blog en 
victorhckinthefreeworld.com 
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Cómo restablecer, revertir y volver a 
estados anteriores en Git 


Por Brent Laster 


Uno de los aspectos menos entendidos (y apreciados) de trabajar con Git es lo fácil que es 
volver a donde estaba antes, es decir, lo fácil que es deshacer incluso los cambios más 
importantes en un repositorio. En este artículo, echaré un vistazo rápido a cómo restablecer, 
revertir y volver por completo a los estados anteriores, todo con la simplicidad y la elegancia 
de los comandos individuales de Git. 


Cómo restablecer (reset) un commit de Git 


Comenzaré con el comando reset de Git. Pde manera práctica, puedes pensar en ello como 
un “retroceso” ('rollback"). Apunta tu entorno local a un commit previo. Por "entorno local", me 
refiero a tu repositorio local, área de preparación (staging area), y directorio de trabajo. 


Echa un vistazo a la Figura 1. En ella puedes ver una representación de una serie de commits 
realizados en Git. Una rama (branch) en Git es simplemente simply un puntero móvil con 
nombre a un commit específico. En este caso la rama master es un puntero al último commit 
en la cadena. 
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Local Repository” 


(Brent Laster, CC BY-SA 4.0) 


Si observas a lo que aparece en tu rama master ahora, puedes ver la cadena de commits 
realizados hasta esta ahora. Puedes ejecutar el siguiente comando que te ofrecerá un listado 
de los commits realizados. 


$ git log --oneline 

b764644 File with three lines 
7C709f0 File with two lines 
9ef9173 File with one line 


Qué ocurre si quieres retroceder a un commit previo. Simple, solo tienes que mover el puntero 
de la rama. Git dispone del comando reset para hacer esto por ti. Por ejemplo, si quieres 
restablecer la rama master a un par de commits anteriores al actual commit, podrías utilizar 
cualquiera de estos dos métodos: 


$ git reset 9ef9173 (utilizando el valor absoluto SHA1 del commit 9ef9173) 


$ git reset current-2 (utilizando el valor relativo -2 después de la etiqueta "current") 
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La Figura 2 muestra el resultado de esta operación. Después de ejecutar el comando git 
log en la rama actual (master), sólo veremos que existe un commit. 


$ git log --oneline 
9ef9173 File with one line 


master 7? 


Local Repository : 


(Brent Laster, CC BY-SA 4.0) 


El comando git reset también incluye opciones para actualizar las otras partes de tu 
entorno local con los contenidos del commit donde has recalado. Estas opciones incluyen: 
hard para restablecer el commit al que ahora apunta al repositorio, extender esos cambios al 
directorio de trabajo con el contenido de commit y restablecer el área de preparación 
(staging area); soft para únicamente restablecer el puntero en el repositorio; y mixed (el 
valor predeterminado) para restablecer el puntero y el área de preparación. 


El uso de estas opciones puede ser útil en determinadas circunstancias, como git reset 
--hard <commit shal | reference>. Esto sobrescribe cualquier cambio local que no 
haya realizado. En efecto, restablece (borra) el área de preparación (staging area) y 
sobrescribe el contenido en el directorio de trabajo con el contenido del commit al que se 
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regresó. Antes de utilizar la opción hard, asegúrate de que eso es lo que realmente quieres 
hacer, ya que el comando sobrescribe cualquier cambio que no se haya confirmado mediante 
un commit. 


Cómo revertir un commit en Git 


El efecto neto del comando git revert es similar al anterior de restablecer (reset), pero su 
enfoque es diferente. Donde el comando reset mueve el puntero de la rama hacia atrás en 
la cadena de commits para "deshacer" los cambios, el comando revert añade un nuevo 
commit al final de la cadena para “cancelar” los cambios. El efecto es más sencillo de 
observar volviendo a la imagen de la Figura 1 de nuevo. Si añades una línea al archivo en 
cada commit en la cadena, una manera de regresar a la versión en la que sólo existían dos 
líneas en el archivo es hacer un reset a ese commit, por ejemplo: git reset HEAD-1. 


Otra forma de llegar a esa versión con únicamente dos líneas en el archivo es añadir un 
nuevo commit en el que esa tercera línea del archivo esté eliminada, cancelando ese último 
cambio. Esto se puede realizar con el comando git revert, así: 


$ git revert HEAD 


Ya que esto añade un nuevo commit, Git te mostrará un mensaje para que añadas un mensaje 
al commit: 


Revert "File with three lines" 
This reverts commit b764644bad524b804577684bf74e7bca3117f554. 


Please enter the commit message for your changes. Lines starting 
with '*+' will be ignored, and an empty message aborts the commit. 
On branch master 
Changes to be committed: 

modified: file1.txt 


Ho 


Si ahora ejecutas de nuevo el comando git log ahora, aparecerá un nuevo commit que 
reflejará el contenido anterios al commit previo. 


$ git log --oneline 

11b7712 Revert "File with three lines" 
b764644 File with three lines 

7C709f0 File with two lines 

9ef9173 File with one line 


Estos son los contenidos actuales del archivo en el directorio de trabajo: 
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$ cat <filename> 
Line 1 
Line 2 


master 


7c7OSfO 


(Brent Laster, CC BY-SA 4.0) 


¿Revertir o restablecer? 


¿Por qué escoger la opción de revert frente a reset? Si ya enviaste (push) tu cadena de 
commits al repositorio remoto (donde otras personas pueden haber descargado tu código y 
comenzado a trabajar con él), usar revertir es una forma más adecuada de cancelar los 
cambios para esas personas. Esto se debe a que el flujo de trabajo de Git funciona bien para 
seleccionar commits adicionales al final de una rama, pero puede ser un problema si un 
conjunto de commits ya no se ven en la cadena cuando alguien restablece el puntero de la 
rama. 


Esto nos lleva a una de las reglas fundamentales cuando se trabaja con Git de esta manera: 
está bien hacer este tipo de cambios en tu repositorio local al código que aún no has enviado 
haciendo push. Pero hay que evitar hacer cambios que reescriban el historial si los commits 
ya se enviaron al repositorio remoto y es posible que otras personas estén trabajando con 
ellos. 


En resumen, si revierte, deshace o reescribe el historial de una cadena de commits con la que 
otras personas están trabajando, estas personas pueden tener mucho más trabajo cuando 
intentan fusionar (merge) los cambios basados en la cadena original que descargaron (pull). 
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Si tienes que realizar cambios en el código que ya se envió (push) y que otras personas están 
utilizando, considera comunicarte antes de realizar la regresión ofrecer la posibilidad a esas 
personas de fusionar (merge) sus cambios primero. Luego, ya pueden descargar (pul!) una 
copia nueva después de la operación que ha revertido los cambios sin necesidad de hacer 
merge. 


Es posible que hayas notado que la cadena original de commits todavía existe aún después 
de que realizar el reinicio. Se movió el puntero y se restableció el código a un commit anterior, 
pero no se eliminó ningun commit. Esto significa que, siempre que conozcas el commit 
original al que estaba apuntando, puedes "restaurar" al punto anterior simplemente 
restableciendo el encabezado original de la rama: 


git reset <sha1 of commit> 


Algo similar sucede en la mayoría de las otras operaciones que realiza en Git cuando se 
reemplazan los commits. Se crean nuevos commits y el puntero se mueve a la nueva cadena. 
Pero la vieja cadena de commits todavía existe. 


Rebase 


Ahora ya puedes echar un vistazo al rebase de ramas. Imagina que en tu repositorio tienes 
dos ramas—master y feature—con la cadena de commits que se muestra en la siguiente 
imagen. Master tiene la cadena C4->C2 ->C1->CO0 y feature tiene la cadena C5->C3->C2- 
>C1->C0. 


Common 
Ancestor 


(Brent Laster, CC BY-SA 4.0) 


feature 


Si echas un vistazo al registro de los commits en las dos ramas, podría tener un aspecto 
como el que se muestra a continuación. (Los designadores con C en los mensajes de los 
commits son utilizados en este ejemplo para hacer más sencilla la explicación). 
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$ git log --oneline master 
6a92e7a C4 
259bf36 C2 
f33ae68 C1 
5043e79 CO 


$ git log --oneline feature 
79768b8 C5 
000f9ae C3 
259bf36 C2 
f33ae68 C1 
5043e79 CO 


Le digo a la gente que piense en un rebase como “una fusión (merge) con historia” en Git. 
Esencialmente, lo que hace Git es tomar cada commit diferente en una rama e intentar 
"reproducir" las diferencias en la otra rama. 


Por lo que puedes hacer un rebase en master para incluir C4 (por ejemplo: insertarlo dentro 
de la cadena de features). Utilizando los comandos básicos de Git, podría ser así: 


$ git checkout feature 
$ git rebase master 


First, rewinding head to replay your work on top of it... 
Applying: C3 
Applying: C5 


Después de eso, tu cadena de commits quedaría como la siguiente imagen: 


feature 


Common 
Ancestor 
(Brent Laster, CC BY-SA 4.0) 


Consulta el registro de commits, donde podrás ver los cambios: 
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$ git log --oneline master 
6a92e7a C4 
259bf36 C2 
f33ae68 C1 
5043e79 CO 


$ git log --oneline feature 
c4533a5 C5 
64f2047 C3 
6a92e7a C4 
259bf36 C2 
f33ae68 C1 
5043e79 CO 


Ten en cuenta que ahora tienes C3' y C5' —nuevos commits creados como resultado de 
realizar los cambios desde los originales “encima” de la cadena ya existente en master. Pero 
también cabe destacar que los commits “originales” C3 y C5 todavía están allí, simplemente 
ya no tienen una rama que los apunte o señale. 


Si realizaste este rebase, y después decidiste que no te gustó el resultado final y quieres 
revertir los resultados, sería tan simple como ejecutar: 


$ git reset 79768b8 


Con este simple cambio, tu rama apuntaría ahora a los mismos grupos de commits que antes 
de la operación de rebase —revirtiéndola de manera efectiva (Figura 6). 


Common 
Ancestor 


feature 


(Brent Laster, CC BY-SA 4.0) 


¿Qué ocurre si no puedes recordar a qué commit apuntaba la rama antes de la operación? 
Afortunadamente, Git nos ayuda con esto. Para la mayoría de las operaciones que modifican 
los punteros de esta manera, Git recuerda cual era el commit original por ti. De hecho, lo 
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almacena en una referencia especial llamada ORIG_HEAD dentro del directorio . git del 
repositorio. Esa ruta es un archivo que contiene las referencias más recientes antes de que 
fueran modificadas. Puedes ver el contenido del archivo con el comando cat . 


$ cat .git/ORIG_HEAD 
79768b891f47ce06f13456a7e222536ee47ad2fe 


También podrías usar el comando reset, como vimos anteriormente, para volver a apuntar a 
la cadena de commits original. El registro mostraría lo siguiente: 


$ git log --oneline feature 
79768b8 C5 
000f9ae C3 
259bf36 C2 
f33ae68 C1 
5043e79 CO 


Otro lugar donde obtener esa información es en el reflog. El reflog es un listado de todas las 
acciones o cambios de referencia en tu repositorio local. Para consultarlo, puedes utilizar el 
comando git reflog 


$ git reflog 

79768b8 HEADO(0): reset: moving to 79768b 

c4533a5 HEADO(1): rebase finished: returning to refs/heads/feature 
c4533a5 HEADO(2): rebase: C5 

64f2047 HEADO(3): rebase: C3 

6a92e7a HEADO(4): rebase: checkout master 

79768b8 HEADO(5): checkout: moving from feature to feature 
79768b8 HEADO(6): commit: C5 

000f9ae HEADOL7): checkout: moving from master to feature 
6a92e7a HEADO(8): commit: C4 

259bf36 HEADOL9): checkout: moving from feature to master 
000f9ae HEADOL10$: commit: C3 

259bf36 HEADO(11): checkout: moving from master to feature 
259bf36 HEADO(12$: commit: C2 

f33ae68 HEADO(13): commit: C1 

5043e79 HEADO(14$: commit (initial): CO 


Luego puedes restablecer cualquiera de los elementos en esa lista usando el formato de 
nombre relativo especial que ve en el registro: 


$ git reset HEADO(1) 
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Una vez que comprendes que Git mantiene la cadena original de commits cuando las 
operaciones "modifican" la cadena, hacer cambios en Git se vuelve mucho menos aterrador. 
Esta es una de las fortalezas centrales de Git: ser capaz de probar cosas de manera rápida y 
fácilmente y deshacerlas si no funcionan. 
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¿Qué es "escoger una cereza” o 
cherry-picking en Git? 


Por Rajeev Bera y Seth Kenlon 


Siempre que trabajes con un grupo de programadores en un proyecto, ya sea pequeño o 
grande, el manejo de cambios entre varias ramas de Git puede volverse difícil. A veces, en 
lugar de combinar una rama completa de Git en una diferente, simplemente se desea 
seleccionar y mover un par de commits específicos. Este procedimiento se conoce como 
"selección de cerezas" o cherry-picking. 


Este artículo tratará sobre eso y el qué, por qué y cómo realizar cherry-picking. 


Así que comencemos. 


¿Qué es cherry-pick? 
Con el comando cherry - pick, Git te permite incorporar commits seleccionados de manera 
individual de cualquier rama en tu rama de Git principal o HEAD. 


Al realizar un git merge o git rebase, todos los commits de una rama se combinan. El 
comando cherry - pick te permite seleccionar de manera individual ciertos commits para 
que se integren. 


Beneficios de realizar un cherry-pick 


La siguiente situación podría facilitar la comprensión de la forma en que funciona la 
selección selectiva o cherry-picking. 


Imagina que estás implementando nuevas funciones para tu próxima reunión semanal. 
Cuando tu código esté listo, lo insertarás en la rama remota, listo para la prueba. 


Sin embargo, el cliente no está satisfecho con todas las modificaciones y solicita que 
presentes solo algunas. Debido a que el cliente no ha aprobado todos los cambios para el 
próximo lanzamiento, el comando git rebase no realizará los resultados deseados. ¿Por 
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qué? Porque git rebaseogit merge incorporarán cada cambio de realizados en las 
reuniones previas 


¡Cherry-picking es la respuesta! Debido a que se enfoca solo en los cambios añadidos en el 
commit, cherry-picking traerá solo los cambios aprobados sin añadir otros commits. 


Hay muchas razones para utilizar cherry-picking: 


+ Es esencial para la corrección de errores porque los errores se establecen en la rama 
de desarrollo utilizando sus commits. 

+ Puedes evitar batallas innecesarias usando git cherry-pick en vez de otras 
opciones que aplican cambios en commits específicos, por ejemplo: git diff. 

+ Esuna herramienta útil si es imposible unir una rama completa debido a versiones 
incompatibles en las distintas ramas de Git. 


Utilizando el comando cherry-pick 


En la forma de uso más simple del comando cherry - pick simplemente puedes utilizar el 
identificador SHA del commit que desees integrar en la rama actual principal HEAD. 


Para obtener el hash del commit puedes utilizar el comando git log 


$ git log --oneline 


Una vez que conoces el hash del commit, puedes usar el comando cherry -pick. La sintaxis 
es: 


$ git cherry-pick <commit sha> 


Por ejemplo: 


$ git cherry-pick 65be1e5 


Esto incluirá el cambio especificado en tu rama actual. 


Si deseas realizar más modificaciones, también puede indicar a Git que agregue cambios de 
commits a tu copia de trabajo. La sintaxis es: 


$ git cherry-pick <commit sha> --no-commit 


Por ejemplo: 


$ git cherry-pick 65be1le5 --no-commit 
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Si deseas seleccionar más de un commit de manera simultánea, agrega sus hashes de 
commits separados por un espacio: 


E git cherry-pick hash1 hash3 


Cuando haces cherry-picking de commits, no puedes utilizar el comando git pull porque 
obtiene (fetch) y fusiona (merge) automáticamente los commits de un repositorio a otro. El 
comando cherry -pick es una herramienta que usas de manera específica para justamente 
no hacer eso. En cambio, utiliza git fetch, que obtiene los cambios pero no los aplica. No 
hay duda de que git pull es útil, pero es impreciso. 


Inténtalo tú mismo 


Para probar el proceso, abre una terminal y genera un proyecto de prueba: 


$ mkdir fruta.git 
$ cd fruta.git 
$ git init . 


Crea algunos archivos con datos y haz un commit: 


$ echo "Kiwi" > fruta.txt 
$ git add fruta.txt 
$ git commit -m 'Primer commit' 


Ahora, vamos a imaginar que existe un desarrollador remoto creando una bifurcación de tu 
proyecto: 


$ mkdir -/fruta.fork 

$ cd !$ 

$ echo "Fresa" >> fruta.txt 

$ git add fruta.txt 

$ git commit -m 'Añadida una fruta" 


Ese es un commit válido. Ahora crea un commit que no sea adecuado, para representar algo 
que no quieres que se añada (merge) a tu proyecto: 


$ echo "Salmón" >> fruta.txt 
$ git add fruta.txt 
$ git commit -m “Añadido un pescado” 


Regresa a tu repositorio autorizado y obtén los commits de tu desarrollador imaginario: 


$ cd -/fruta.git 
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$ git remote add dev -/fruta.fork 

$ git fetch dev 

remote: Counting objects: 6, done. 

remote: Compressing objects: 100% (2/2), done. 
remote: Total 6 (delta 0), reused O (delta 0) 
Unpacking objects: 100% (6/6), done... 


$ git log -oneline dev/master 
e8g58ab2 Añadido un pescado 
0664292 Añadida una fruta 
b56e0f8 Primer commit 


Has descargado (fetch) los commits de tu desarrollador imaginario, pero todavía no los has 
integrado (merge) en tu repositorio. Quieres aceptar el segundo commit, pero no el tercero, 
así que usaremos cherry-pick: 


$ git cherry-pick 0664292 


El segundo commit ahora está en tu repositorio: 


$ cat fruit.txt 
Kiwi 
Fresa 


Envía tus cambios (push) al servidor remoto que hospeda el repositorio git ¡y ya está! 


Razones para evitar realizar cherry-picking 


Cherry-picking generalmente se desaconseja en la comunidad de desarrolladores. La razón 
principal es que crea commits duplicados, pero también pierde la capacidad de rastrear su 
historial de commits. 


Si estás seleccionando una gran cantidad de commits fuera de orden, esos commits se 
guardarán en tu rama y podrían generar resultados no deseados en tu rama de Git. 


Cherry-pick es un comando poderoso que podría causar problemas si se usa sin una 
comprensión adecuada de lo que podría ocurrir. Sin embargo, puede salvarle la vida (o al 
menos tu trabajo diario) cuando te equivocas y se realizan commits en las ramas 
equivocadas. 
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Encuentra qué fue lo que cambió en 
un commit de Git 


Por Seth Kenlon 


Si utilizas Git cada día, es probable que realices muchos commits. Si utilizas Git cada día en 
un proyecto junto con otras personas, es justo asumir que todas esas personas realizan 
muchos commits. Cada día. Y esto significa que eres consciente de lo desorientador que 
puede volverse un log de los cambios de Git, con una lista aparentemente eterna de cambios 
y sin señales de lo que se ha cambiado. 


Entonces, ¿cómo saber qué archivo cambió en un commit específico? Es más fácil de lo que 
piensas. 


Encuentra qué archivo cambió en un commit 


Para averiguar qué archivos cambiaron en un commit específico, utiliza el comando git log 
- - raw. Es la forma más rápida y sencilla de obtener información sobre los archivos a los 
que afecta un commit. El comando git log en general está infrautilizado, en gran medida 
porque tiene muchas opciones de formato y muchas personas se sienten abrumadas por 
disponer de demasiadas opciones y, en algunos casos, por una documentación poco clara. 


El mecanismo de log en Git es sorprendentemente flexible, y la opción - - raw ofrece un 
registro de commits de la rama actual, además de una lista de cada archivo en el que se 
realizaron cambios.. 


Esta es la salida de un estándar git log: 


$ git log 

commit fbbbe083aed75b24f2c77b1825ecab10def0953c (HEAD -> dev, origin/dev) 
Author: tux <tuxfWexample.com> 

Date: Sun Nov 5 21:40:37 2020 +1300 


exit immediately from failed download 


commit 094f9948cd995acfc331a6965032ea0d38e01f03 (origin/master, master) 


Creative Commons Attribution Share-alike 4.0 17 


Author: Tux <tuxfWexample.com> 
Date: Fri Aug 5 02:05:19 2020 +1200 


export makeopts from etc/example.conf 
commit 76b7b46dc53ec13316abb49cc7b37914215acd47 


Author: Tux <tuxfdexample.com> 
Date: Sun Jul 31 21:45:24 2020 +1200 


fix typo in help message 


Incluso cuando el autor especifica amablemente en el mensaje de commit qué archivos 
cambiaron, el registro es bastante conciso. Esta es la salida de git log --rawm: 


$ git log --raw 

commit fbbbe083aed75b24f2c77b1825ecab10def0953c (HEAD -> dev, origin/dev) 
Author: tux <tuxfWexample.com> 

Date: Sun Nov 5 21:40:37 2020 +1300 


exit immediately from failed download 
:100755 100755 cbcf1f3 4cac92f M src/example. lua 
commit 094f9948cd995acfc331a6965032ea0d38e01f03 (origin/master, master) 
Author: Tux <tuxfWdexample.com> 
Date: Fri Aug 5 02:05:19 2020 +1200 
export makeopts from etc/example.conf 
:100755 100755 4c815c0 cbcf1f3 M src/example. lua 
:100755 100755 71653e1 8f5d5a6 M src/example.spec 
:100644 100644 9d21a6f e33caba R100 etc/example.conf etc/example.conf-default 
commit 76b7b46dc53ec13316abb49cc7b37914215acd47 
Author: Tux <tuxfWexample.com> 
Date: Sun Jul 31 21:45:24 2020 +1200 


fix typo in help message 


:100755 100755 e253aaf 4c815c0 M src/example. lua 


Esto le indica exactamente qué archivo se agregó al commit y cómo se modificó el archivo (A 


para añadido, M para modificado, R para renombrado y D para eliminado). 
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Git whatchanged 


El comando git whatchanged es un comando heredado anterior a la función de log. Su 
documentación dice que no está destinado a ser usado, y mejor utilizar git log --raw lo 
que implica que está esencialmente en desuso. Sin embargo, todavía lo encuentro un atajo 
útil para (principalmente) el mismo resultado (aunque se excluyen los commits de fusión 
(merge)), y anticipo crear un alias para él en caso de que alguna vez se elimine. Si no 
necesitas fusionar (merge) commits en su log (y probablemente no lo necesites, si solo estás 
buscando ver qué archivos cambiaron), prueba git whatchanged como un nombre fácil de 
recordar. 


Ver cambios 


No solo puedes ver qué archivos cambiaron, si no que también puedes hacer que git log 
muestre exactamente los cambios en esos archivos. Git log puede mostrar las diferencias en 
una línea, mostrarlos línea a línea de todos los cambios de cada archivo con la opción - - 
patch: 


commit 62a2daf8411ecchbec0af69e4736a0fcf0a469ab1 (HEAD -> master) 
Author: Tux <Tuxfdexample.com> 
Date: Wed Mar 10 06:46:58 2021 +1300 


commit 


diff --git a/hello.txt b/hello.txt 
index 65a56c3..36a0a7d 100644 
--- a/hello.txt 
+++ b/hello.txt 
00 -1,2 +1,2 00 
Hello 
-wor ld 
+opensource.com 


En este ejemplo, la línea con una única palabra "world" fue eliminada del archivo hello.txt 
y se añadió una nueva línea que contiene el texto "opensource.com'. 


Estos parches se pueden usar con utilidades comunes de Unix como diff y patch, en caso de 
que se necesite realizar los mismos cambios manualmente en otro lugar. Los parches 
también son una buena manera de resumir las partes importantes de la información nueva 
que introduce un commit específico. Esta es una descripción general valiosa cuando se ha 
cometido un error. Para encontrar la causa del error más rápido, puedes ignorar las partes de 
un archivo que no cambiaron y revisar unicamente el código nuevo. 
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Comandos simples para resultados complejos 


No es necesario saber sobre referencias y ramas y hashes de commits para ver qué archivos 
cambiaron en un commit. El log de Git se diseñó para informar sobre la actividad de Git, y si 
deseas formatearlo de una manera específica o extraer información específica, a menudo es 
cuestión de navegar a través de muchas pantallas de documentación para conseguir el 
comando correcto que te muestre la información que deseas. Afortunadamente, una de las 
solicitudes más comunes sobre el log de Git está disponible con solo una o dos opciones.: - - 
raw y - - patch. Y si no te acuerdas de - - raw, simplemente piensa (en inglés), "Git, ¿qué 
cambió?" y escribe git whatchanged. 
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Experimenta con tu código 
libremente con Git worktree 


Por Seth Kenlon 


Git está diseñado en parte para permitir la experimentación. Cuando ya sabes que tu trabajo 
está a salvo estando monitorizado y existen estados seguros a los que regresar sin algo 
horrible sucede, ya no temes a intentar nuevas ideas. Sin embargo, parte del precio de la 
innovación es asumir que puedes liarlo todo en esas pruebas. Los archivos se renombran. Se 
cambian de sitio, cambian y cortas cosas de ellos. Se añaden nuevos archivos. Archivos 
temporales que no tienes intención de mantenerlos ahora residen en tu directorio de trabajo. 


En resumen, tu espacio de trabajo se convierte en una especie de castillo de naipes, que se 
balancea de manera precaria entre "¡casi funciona!” y "oh no, ¿qué he hecho?”. ¿Qué ocurre 
cuando necesitas que tu repositorio regrese a un estado conocido por un tiempo, para 
realizar trabajo de verdad? Los comandos clásico git branch y git stash quizás te vienen 
enseguida a la cabeza, pero ninguno de ellos está diseñado para gestionar, de una manera u 
otra, archivos que no tienen seguimiento en tu repositorio o rutas de archivos que han 
cambiado u otros cambios importantes pueden hacer que sea confuso guardar (stash) ese 
trabajo para más adelante. La respuesta es Git worktree. 


Qué es un Git worktree 


Un árbol de trabajo de Git o Git worktree, es una copia vinculada de su repositorio de Git, lo 
que le permite tener varias ramas desprotegidas a la vez. Un worktree tiene una ruta separada 
de tu copia de trabajo principal, pero puede estar en un estado diferente en una rama 
diferente. La ventaja de una nueva rama de trabajo en Git es que puedes realizar un cambio 
no relacionado con tu tarea actual y después fusionarla (merge) más adelante, todo sin 
interferir con tu entorno de trabajo actual. 


El ejemplo más típico, extraido directamente de la página de ayuda de git -worktree, es en 
el que estás trabajando en una nueva funcionalidad muy interesante para un proyecto, 
cuando tu jefe de proyecto te dice que es necesario solucionar de manera urgente un error. El 
problema es que tu repositorio de trabajo (tu "worktree") está todo desordenado porque 
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estabas enfrascado en la tarea de desarrollar una funcionalidad muy importante. No quieres 
incluir esa solución urgente en tu sesión actual y no te sientes cómodo guardando el 
contenido actual mediante stash para crear una rama nueva para esa solución urgente. En 
vez de eso decides crear una rama de trabajo nueva en la que desarrollar la solución urgente: 


$ git branch | tee 

* dev 

trunk 

$ git worktree add -b hotfix -/code/hotfix trunk 
Preparing ../hotfix (identifier hotfix) 

HEAD is now at 62a2daf commit 


En tu directorio de trabajo ahora tienes un nuevo directorio llamado hotfix, que es un 
worktree enlazado a tu repositorio principal, con su HEAD apuntando a la rama llamada 
trunk. Ahora puedes tratar esta rama de trabajo o worktree como si estuvieras en tu espacio 
de trabajo principal. Puedes cambiar a ese directorio, realizar los cambios que son tan 
urgentes, realizar el commit y después incluso si quieres eliminar ese worktree: 


$ cd -/code/hotfix 
$ sed -i 's/teh/the/' hello.txt 
$ git commit --all --message 'urgent hot fix' 


Una vez que acabes el trabajo urgente, puedes regresar a tu tarea anterior. Tienes el control 
de cuando se integren tu revisión, esta se integre en el proyecto principal. Por ejemplo, 
puedes enviar los cambios directamente desde su worktree al repositorio remoto del 
proyecto: 


$ git push origin HEAD 
$ cd -/code/myproject 


O puedes archivar el worktree como un archivo TAR o ZIP: 


$ cd -/code/myproject 
$ git archive --format tar --output hotfix.tar master 


O puedes obtener los cambios de manera local desde el worktree separado: 


$ git worktree list 
/home/seth/code/myproject 15fca84 [dev] 
/home/seth/code/hotfix 09e585d [master] 


A partir de ahí, puedes fusionar tus cambios utilizando lo más adecuado para ti y las 
personas de tu equipo. 
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Listando los worktrees activos 


Puedes hacer que se muestre un listado de los worktrees y ver qué rama tiene cada uno 
utilizando el comando git worktree list: 


$ git worktree list 
/home/seth/code/myproject 15fca84 [dev] 
/home/seth/code/hotfix 09e585d [master] 


Puedes usar esto desde cualquier worktree. Los worktree siempre están vinculados (a menos 
que los muevas manualmente a otra ubicación, rompiendo la capacidad de Git para ubicar un 
worktree y, por lo tanto, cortando ese vínculo). 


Moviendo un worktree 


Git rastrea la ubicación y estados de los worktree en el directorio. git de tu proyecto: 


$ cat -/code/myproject/.git/worktrees/hotfix/gitdir 
/home/seth/code/hotfix/.git 


Si necesitar reubicar un worktree, debes hacerlo empleando git worktree move; si no, 
cuando Git trate de actualizar el estado de ese worktree, fallará: 


$ mkdir —-/Temp 

$ git worktree move hotfix -—/Temp 

$ git worktree list 
/home/seth/code/myproject 15fca84 [dev] 
/home/seth/Temp/hotfix 09e585d [master] 


Eliminar un worktree 


Cuando termines con tu trabajo, puedes eliminarlo con el subcomando remove: 


$ git worktree remove hotfix 
$ git worktree list 
/home/seth/code/myproject 15fca84 [dev] 


Para asegurarte que tu directorio . git está limpio, utiliza el subcomando prune después de 
eliminar un worktree: 


$ git worktree prune 
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Cuándo utilizar los worktrees 


Al igual que con muchas opciones, ya sean pestañas, marcadores o copias de seguridad 
automáticas, depende de ti realizar un seguimiento de los datos que genera, o podría volverse 
abrumador. No utilices worktrees con tanta frecuencia que termines con 20 copias de tu 
repositorio, cada una en un estado ligeramente diferente. Me parece mejor crear una rama de 
trabajo, hacer la tarea que lo requiere, enviar el commit con el trabajo y luego eliminar la rama. 
Mantente simple y enfocado. 


Lo importante es que los worktree brindan una mayor flexibilidad en la forma en que 
administra un repositorio de Git. Úsalos cuando los necesites, y nunca más te esfuerces por 
preservar su estado de trabajo (stash) solo para verificar algo en otra rama. 
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4 consejos para cambiar de contexto 
en Git 


Por Olaf Alders 


Cualquiera que pase mucho tiempo trabajando con Git se habrá encontrado con la necesidad 
de realizar algún tipo de cambio de contexto. A veces, esto agrega muy poca sobrecarga a tu 
flujo de trabajo, pero otras veces, puede ser un verdadero dolor de cabeza. 


Analicemos los pros y los contras de algunas estrategias comunes para lidiar con el cambio 
de contexto utilizando este problema de ejemplo: 


Imagina que estás trabajando en una rama llamada función-X. Acabas de 
descubrir que necesitas resolver un problema no relacionado. Esto no se puede 
hacer en función-X. Deberás realizar este trabajo en una nueva rama, 
característica-Y. 


Solución +1: stash + branch 
Probablemente, el flujo de trabajo más común para abordar este problema se parezca a esto: 


. Detén el trabajo en la función -X 

. git stash 

. git checkout -b característica-Y origin/main 
. Escribes tu código en esa rama 

. git checkout función-Xogit switch - 

. git stash pop 

7. Vuelves al trabajo en la función -X 


D0o0oh0Nn A 


Pros: Lo bueno de este enfoque es que este es un flujo de trabajo bastante fácil para 
cambios simples. Puede funcionar bastante bien, especialmente para repositorios pequeños. 


Contras: Al usar este flujo de trabajo, solo puedes tener un espacio de trabajo a la vez. 
Además, dependiendo del estado de tu repositorio, trabajar con stash puede no ser trivial. 
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Solución +2: WIP commit + branch 


Una variación de esta solución es bastante similar, pero utiliza un commit WIP (trabajo en 
grogreso por sus iniciales en inglés: Work in Progress) en vez de el comando stash. Cuando 
estés preparado para regresar, en vez de ejecutar git stash pop, ejecutas un git reset 
HEAD-1 que despliega de nuevo el commit WIP, y eres libre de continuar, como lo hiciste en el 
escenario anterior pero sin usar stash. 


. Detén el trabajo en la función -X 

. git add -u (añade solo los archivos modificados o eliminados) 
git commit -m "WIP" 

. git checkout -b caracterísitica-Y origin/master 

. Escribes tu código en esa rama 

. git checkout feature-Xogit switch - 

7. git reset HEAD-1 


DIAN 


Pros: Este es un flujo de trabajo fácil para cambios simples y también es bueno para 
repositorios pequeños. No tienes que trabajar con stash. 


Contras: Solo puede tener un espacio de trabajo a la vez. Además, los commits de WIP 
pueden colarse en su producto final si tu o tu revisor de código no estáis atentos. 


Al usar este flujo de trabajo, nunca deberás añadir un - -hard to git reset. Si haces esto 
de manera accidental, deberías poder restaurar tu commit usando git ref log, pero es más 
recomendable evitar este escenario por completo. 


Solucion +3: clon del nuevo repositorio 


En esta solución, en lugar de crear una nueva rama, crea un nuevo clon del repositorio para 
cada nueva rama de características. 


Pros: Puedes trabajar en múltiples espacios de trabajo de manera simultánea. No necesitas 
usar git stash ni usar commits WIP. 


Contras: Dependiendo del tamaño de tu repositorio, esto puede usar mucho espacio en disco. 
(Los clones superficiales pueden ayudar con este escenario, pero es posible que no siempre 
encajen bien). Además, los clones de tu repositorio serán independientes entre sí. Como no 
pueden rastrearse entre sí, debes rastrear dónde residen tus clones. Si necesitas git hooks, 
deberás configurarlos para cada clon nuevo. 
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Solución +4: git worktree 


Para usar esta solución, deberás aprender sobre el comando git add worktree. No te 
sientas mal si no estás familiarizado con los árboles de trabajo o worktree en Git. Muchas 
personas se las arreglan durante años en una feliz ignorancia de este concepto. 


¿Qué es un worktree? 


Piensa en un worktree como los archivos en el repositorio que pertenecen a un proyecto. 
Esencialmente, es una especie de espacio de trabajo. Puede que no te des cuenta que ya 
estás utilizando worktrees. Cuando usas Git, ahí ya está usando un worktree. 


$ mkdir /tmp/foo ££ cd /tmp/foo 
$ git init 

$ git worktree list 

/tmp 0000000 [master] 


Como puedes ver, el worktree existe incluso antes que el primer commit. Ahora añade un 
nuevo worktree a un proyecto ya existente. 


Añadir un worktree 
Para añadir un nuevo worktree, necesitas indicar: 
1. Una ubicación en el disco 


2. Un nombre de rama 
3. Algo desde lo que ramificar 


$ git clone https://github.com/oalders/http-browserdetect.git 
$ cd http-browserdetect/ 

$ git worktree list 

/Users/olaf/http-browserdetect 90772ae [master] 


$ git worktree add -/trees/oalders/feature-X -b oalders/feature-X origin/master 
$ git worktree add -/trees/oalders/feature-Y -b oalders/feature-Y 
e9df3c555e96b3f1 


$ git worktree list 

/Users/olaf/http-browserdetect 90772ae [master] 
/Users/olaf/trees/oalders/feature-X 90772ae [oalders/feature-X] 
/Users/olaf/trees/oalders/feature-Y e9df3c5 [oalders/feature-Y] 


Al igual que con la mayoría de los otros comandos de Git, debes estar dentro de un 
repositorio al ejecutar este comando. Una vez que se crean los worktree, tienes entornos de 


trabajo aislados. El repositorio de Git rastrea dónde se ubican los worktree en el disco. Si los 
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Githooks ya están configurados en el repositorio principal, también estarán disponibles en los 
nuevos worktree. 


No hay que pasar por alto que cada worktree usa solo una fracción del espacio en disco del 
repositorio principal. En este caso, el worktree requiere aproximadamente un tercio del 
espacio en disco del original. Esto puede escalar muy bien. Cuando tus repositorios se midan 
en gigabytes, es cuando mejor apreciarás estos ahorros de espacio. 


$ du -sh /Users/olaf/http-browserdetect 


$ du -sh /Users/olaf/trees/oalders/feature-X 


Pros: Puedes trabajar en múltiples espacios de trabajo simultáneamente. No necesitas stash. 
Git rastrea todos tus worktree. No necesitas configurar los Git hooks. Esto también es más 
rápido que git clone y puede ahorrar tráfico de red, ya que puedes hacerlo sin conexión a 
la red. También obtiene un uso más eficiente del espacio en disco sin necesidad de recurrir a 
un clon superficial. 


Contras: Este es otro comando más a memorizar. Sin embargo, si puedes adquirir el hábito 
de usar este comando, puede que te compense generosamente. 


Algunos consejos más 


Cuando necesites limpiar tus worktree, hay un par de opciones. La forma preferible es dejar 
que Git elimine el árbol de trabajo: 


git worktree remove /Users/olaf/trees/oalders/feature-X 


Si prefieres utilizar una opción que no deja rastro, rm -rf también es tu amigo: 


rm -rf /Users/olaf/trees/oalders/feature-X 


Sin embargo, si realizas esto, quizás quieras limpiar cualquier rastro mediante git 
worktree prune. O puedes obviar el comando prune ahora, y eso ocurrirá por sí mismo en 
algún momento medante git gc. 
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Notas importantes 


Si te sientes ya preparado a usar git worktree, aquí tienes algunas cosas a tener en 
cuenta: 


+ El eliminar un worktree no elimina una rama. 

+ Puedes cambiar entre ramas dentro de un worktree. 

+ No puedes hacer check out a la misma rama al mismo tiempo en múltiples worktrees. 

* Como muchos otros comandos de Gi, git worktree necesita ser ejecutado dentro 
de un repositorio rastreado por Git. 

» Puedes tener múchos worktrees al mismo tiempo. 

+ Creetus worktree desde el misma rama local, o serán independientes entre sí. 


git rev-parse 


Una última nota: Cuando uses git worktree, tu concepto de dónde se ubica la raíz del 
repositorio depende del contexto. Afortunadamente, git rev-parse te permite distinguir 
entre las dos: 


+ Para encontrar la raíz del repositorio principal: 


git rev-parse --git-common-dir 


+ Para encontrar la raíz del repositorio en el que te encuentras: 


git rev-parse --show-toplevel 


Escoge el mejor método para tus necesidades 


Como en muchos casos, hay más de una forma de realizar las cosas. Lo importante es que 
encuentres un flujo de trabajo que se ajuste a tus necesidades. Tus necesidades pueden 
variar según el problema en que te encuentres. Tal vez de vez en cuando te encuentres 
buscando git worktree como una herramienta útil en tu cinturón de herramientas usando 
Git. 
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Una guía práctica para usar el 
comando git stash 


Por Ramakrishna Pattnaik 


El control de versiones es una parte inseparable de la vida diaria de los desarrolladores de 
software. Es difícil imaginar que un equipo desarrolle software sin utilizar una herramienta de 
control de versiones. Es igualmente difícil imaginar a un desarrollador que no haya trabajado 
con (o al menos oído hablar de) Git. 


Este capítulo recorre el comando git stash y explora algunas opciones útiles para usar el 
comando. Se supone que tienes una familiaridad básica con los conceptos de Git y una 
buena comprensión del árbol de trabajo, el área de preparación y los comandos asociados. 


¿Por qué es importante git stash? 


Lo primero que hay que entender es por qué es importante Git stash. Supongamos por un 
momento que Git no tiene un comando para reservar los cambios. Supongamos que estás 
trabajando en un repositorio con dos ramas, A y B. Las ramas A y B se han separado durante 
bastante tiempo y tienen incios diferentes. Mientras estás trabajado en algunos archivos en 
la rama A, tu equipo te pide que corrijas un error en la rama B. Rápidamente guardas tus 
cambios en A e intentas sincronizar la rama B mediante git checkout B. Git cancela la 
operación de manera inmediata y muestra el error, "Sus cambios locales de los siguientes 
archivos serán sobreescritos por checkout ... Por favor, haga un commit de sus cambios o 
haga stash antes de cambiar de ramas." 


En este caso hay algunas formas de habilitar el cambio de rama: 


* Crear un commit en ese punto en la rama A, hacer commit y push de los cambios para 
solucionar el error en B, y después cambiar de nuevo a A y ejecutar git reset 
HEADA para regresar tus cambios de nuevo. 

+ Guardar de manera manual los cambios en archivos no rastreados por Git. 
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El segundo método es una mala idea. El primer método, aunque parece convencional, es 
menos flexible porque los cambios guardados sin terminar se tratan como un punto de 
control en lugar de un parche que aún es un trabajo en progreso. Este es exactamente el tipo 
de escenario para el que git stash está diseñado. 


Git stash guarda los cambios locales que no se han hecho un commit, permitiéndote realizar 
cambios, cambiar de ramas y realizar otras operaciones con git. Después puedes volver a 
aplicar los cambios almacenados con stash cuando los necesites. El comando stash tiene un 
alcance local y no se envía al repositorio remoto mediante git push. 


Cómo utilizar git stash 
Esta es la secuencia a seguir al usar git stash: 


. Guarda los cambios en la rama A. 

. Ejecuta git stash. 

. Cambia a la rama B. 

. Soluciona el error en la rama B. 

. Haz un commit y (si lo deseas) envía los cambios al repositorio remoto con push. 
. Cambia a la rama A 

7. Ejecuta git stash pop para recuperar los cambios guardados. 


D0o0=hO0ON a 


Git stash almacena los cambios que has realizado en el directorio de trabajo de manera local 
(dentro del directorio del proyecto de .git; / .git/refs/stash, para ser más precisos) y te 
permite recuperar los cambios cuando los necesites. Es útil cuando necesitas cambiar entre 
contextos. Te permite guardar los cambios que puedas necesitar en una etapa posterior y es 
la forma más rápida de limpiar tu directorio de trabajo mientras mantienes los cambios 
intactos. 


Cómo crear un stash 


El comando más simple para almacenar tus cambios es git stash: 


$ git stash 
Directorio de trabajo y estado de índice WIP on master: 657a36d ejemplo commit 
guardados 


De manera predeterminada, git stash almacena los cambios de los que no se han 
realizado un commit y pasa por alto los archivos no rastreados por git o los ignorados. Por lo 
general, no es necesario guardar archivos sin seguimiento e ignorados, pero a veces pueden 
interferir con otras cosas que desees hacer en tu código. 
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Puedes utilizar opciones adicionales para permitira git stash tomar el contros de los 
archivos sin seguimiento o ignorados: 


* git stash -uogit stash --include-untracked almacena archivos sin 
seguimiento. 

* git stash -aogit stash --all almacena archivos sin seguimiento e 
ignorados. 


Para almacenar archivos específicos, puedes utilizar el comando git stash -pogit 
stash -patch: 


$ git stash --patch 
diff --git a/.gitignore b/.gitignore 
index 32174593..8d81be6e 100644 
--- a/.gitignore 
+++ b/.gitignore 
00 -3,6 +3,7 QQ 

+ dependencies 

node_modules/ 

/.pnp 
+f, fmfm 

-pnp.js 


$ testing 
(1/1) Stash this hunk [y,n,q,a,d,e,?]? 


Mostrar un listado de tus stash 


Puedes ver un listado de los cambios almacenados con stash con el comando git stash 
list. Los stash son guardado en modo de pila LIFO (Last-In-First-Out o el último en entrar es 
el primero en salir: 


$ git stash list 
stash0(0): WIP on master: d7435644 Feat: configure graphql endpoint 


De forma predeterminada, los stash se marcan como WIP en la parte superior de la rama y el 
commit a partir de la cual creó el stash. Sin embargo, esta cantidad limitada de información 
no es muy útil cuando tienes múltiples stash y se vuelve difícil recordar o verificar 
individualmente sus contenidos. Para añadir una descripción al stash, puedes utilizar el 
comando git stash save <descripcion>: 


$ git stash save "eliminar punto y coma del código" 
Saved working directory and index state On master: eliminar punto y coma del 
código 
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$ git stash list 
stash0(0): On master: eliminar punto y coma del código 
stash0(1): WIP on master: d7435644 Feat: configure graphql endpoint 


Recuperar cambios almacenados 


Puedes volver a aplicar los cambios almacenados con stash con los comandos git stash 
apply y git stash pop. Ambos comandos vuelven a aplicar los cambios almacenados en 
el último stash (eso es, stash0£07). Un apply vuelve a aplicar los cambios mientras que 
pop elimina los cambios del stash y los vuelve a aplicar a la copia de trabajo. Ejecutar pop es 
mejor si no necesitas volver a aplicar los cambios almacenados más de una vez. 


Puedes elegir qué stash deseas hacer pop o aplicar pasando el identificador como último 
argumento: 


$ git stash pop stash0(1) 


10) 


$ git stash apply stash0(1) 


Limpiando stash 


Es una práctica recomendable, el limpiar los stash almacenados y que ya no se van a 
necesitar más. Para hacerlo, debes ejecutar alguno de los siguientes comandos: 


+ git stash clear vacía la lista de stash eliminado todo lo almacenado. 
* git stash drop <stash_id> elimina únicamente un stash en particular de la lista. 


Comprobando las diferencias entre stash 


El comando git stash show <stash_id> te permite ver las diferencias con un stash: 


$ git stash show stash0(1) 


console/console-init/ui/.graphqlrc.yml | 4 +- 
console/console-init/ui/generated-frontend.ts | 742 +4+++++444=-=------- 
console/console-init/ui/package.json | 2 +- 


Para obtener una información más detallada de las diferencias, añade la opción - -patcho - 
p 


$ git stash show stash0(0) --patch 
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diff --git a/console/console-init/ui/package.json 
b/console/console-init/ui/package.json 

index 755912b97..5b5af1bd6 100644 

--- a/console/console-init/ui/package.json 

+++ b/console/console-init/ui/package.json 

00 -1,5 +1,5 00 


t 
- "name": '"my-usepatternfly", 
+ "name": '"my-usepatternfly-2", 
"version": "0.1.0", 


"private": true, 
"proxy": "http://localhost:4000" 
diff --git a/console/console-init/ui/src/AppNavHeader.tsx b/console/console- 
init/ui/src/AppNavHeader.tsx 
index a4764d2f3..da72b7e2b 100644 
--- a/console/console-init/ui/src/AppNavHeader.tsx 
+++ b/console/console-init/ui/src/AppNavHeader.tsx 
00 -9,8 +9,8 (00 import [ css j from "QMpatternfly/react-styles"; 


interface IAppNavHeaderProps extends PageHeaderProps f 
- toolbar?: React.ReactNode; 
- avatar?: React.ReactNode; 
+ toolbar?: React.ReactNode; 
+ avatar?: React.ReactNode; 
J 


export class AppNavHeader extends React.Component<IAppNavHeaderProps>f 
render() 


Cambiando a una nueva rama 


Puede ser que te encuentres en la situación en la que los cambios en una rama y tu stash 
sean diferentes, causando un conflicto cuando intentas volver a aplicar el stash. Una solución 
es utilizar el comando git stash branch <nombre_nueva_rama stash_id>, que crea 
una nueva rama basada en el commit desde el que se creó stash y recupera allí los cambios 
almacenados: 


$ git stash branch test_2 stash0(0) 

Switched to a new branch 'test_2' 

On branch test_2 

Changes not staged for commit: 

(use "git add <file>..." to update what will be committed) 

(use "git restore <file>...'" to discard changes in working directory) 
modified: .graphqlrc.yml 

modified: generated-frontend.ts 

modified: package.json 
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no changes added to commit (use "git add" and/or "git commit -a") 
Dropped stash0L0y (fe4bf8f79175b8fbd3df3c4558249834ecb75cd1) 


Realizando un stash sin alterar el log de referencia (reflog) 


En alguna rara circunstancia, podrías necesitar crear un stash mientras mantienes intacto el 
log de referencia (o reflog) del stash. Estos casos podrían aparecer cuando necesitas un 
script para hacer stash como un detalle de implementación. Esto se logra mediante el 
comando git stash create; esto crea una entrada stash y devuelve su nombre de objeto 
sin enviarlo al stash reflog: 


$ git stash create "sample stash" 
63a711cd3c7f8047662007490723e26ae9d4acf9 


A veces, puedes decidir enviar (push) la entrada del stash mediante git stash store 
para almacenar el log de referencia: 


$ git stash store -m "sample stash testing.." 
"63a711cd3c7f8047662007490723e26ae9d4acf9" 

$ git stash list 

stash (010%: sample stash testing. . 
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Cómo renombrar una rama, borrar 
una rama o encontrar el autor de una 
rama en Git 


Por Agil Antony 


Una de las principales fortalezas de Git es su capacidad para "bifurcar" (fork en inglés) el 
trabajo en diferentes ramas. 


Si eres la única persona que usa un repositorio, los beneficios son modestos, pero una vez 
que comiences a trabajar con muchos otros colaboradores, la bifurcación es esencial. El 
mecanismo de bifurcación de Git permite que varias personas trabajen en un proyecto, e 
incluso en el mismo archivo, al mismo tiempo. Los usuarios pueden introducir diferentes 
funciones, independientes entre sí, y luego fusionar los cambios en una rama principal más 
adelante. Una rama creada de manera específica para un propósito, como añadir una nueva 
funcionalidad o solucionar un error conocido, es a veces llamada una rama temática o topic 
branch. 


Una vez que empieces a trabajar con ramas, es útil saber cómo administrarlas. Estas son las 
tareas más comunes que las personas que desarrollan código realizan con las ramas de Git 
en el mundo real. 


Renombrar una rama en Git 


Cambiar el nombre de una rama es útil si le has puesto un nombre erróneo o has nombrado a 
una rama de manera incorrecta o quieres utilizar la misma rama para trabajar en diferentes 
errores o tareas después de fusionar el contenido en la rama principal. 


Renombrar una rama local 


1. Renombrar la rama local: 


$ git branch -m <nombre_anttiguo> <nuevo_nombre> 
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Esto solo renombra tu copia local de la rama. Si la rama existe en un servidor remoto de Git, 
deberás ejecutar además estos pasos: 


2. Hacer push de la nueva rama, para crear la rama en el repositorio remoto: 


$ git push origin <nuevo_nombre> 


3. Eliminar la rama remota antigua: 


$ git push origin -d -f <nombre_antiguo> 


Renombrar la rama actual 


Cuando la rama que quieres renombrar es tu rama actual, no necesitas especificar el nombre 
ya existente de la rama. 


1. Renombrar la rama actual: 


$ git branch -m <nuevo_nombre> 


2. Haz push de la nueva rama para crear una nueva rama remota: 


$ git push origin <nuevo_nombre> 


3. Elimina la rama remota antigua: 


$ git push origin -d -f <nombre_antiguo> 


Eliminar ramas locales y remotas en Git 


Una buena práctica para mantener limpio el repositorio, a menudo se recomienda que 
eliminar una rama después de asegurarse de haber fusionado el contenido en la rama 
principal. 


Eliminar una rama local 


Al eliminar una rama local, solo se elimina la copia de esa rama que existe en tu equipo. Si la 
rama ya se envió al repositorio remoto, permanece disponible para todos los que trabajan con 
el repositorio. 


1. Cambia a la rama principal de tu repositorio (normalmente se llama main o master): 


$ git checkout <central_branch_name> 
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2. Lista todas las ramas (tanto locales como remotas): 


$ git branch -a 


3. Elimina la rama local: 


$ git branch -d <nombre_de_la_rama> 


Para eliminar todas las ramas y mantener únicamente la rama principal llamada main: 


$ git branch | grep -v main | xargs git branch -d 


Eliminar una rama remota 


Eliminar una rama remota solo elimina la copia de esa rama que existe en el servidor remoto. 
Si después de hacerlo, decides que no deseas eliminar la rama, puedes volver a enviarla al 
repositorio remoto, como GitLab, siempre que aún tengas tu copia local en tu equipo. 


1. Cambia a la rama principal de tu repositorio (normalmente llamada main o master): 


$ git checkout <nombre_de_la_rama_principal> 


2. Lista todas las ramas (locals y remotas): 


$ git branch -a 


3. Elimina la rama remota: 


$ git push origin -d <nombre_de_la_rama> 


Encuentra al autor del nombre de una rama remota en Git 


Si eres el administrador del repositorio, es posible que debas hacer esto para poder informar 
al autor de una rama no utilizada que debe eliminarse. 


1. Cambia a la rama principal de tu repositorio (normalmente llamada main o master): 


$ git checkout <nombre_de_la_rama_principal> 


2. Elimina las referencias a ramas remotas que no existen: 


$ git remote prune origin 
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3. Muestra un listado del autor de todas las ramas remotas del repositorio, utilizando la 
opción - - format junto con otras opciones (en este ejemplo, %(authorname) y % 
(refname) para ver el nombre del autor y de la rama) para mostrar solo la información que 
deseas: 


$ git for-each-ref --sort=authordate --format='%(authorname) %(refname)' 
refs/remotes 


Información mostrada de ejemplo: 


tux refs/remotes/origin/dev 
agil refs/remotes/origin/main 


Puedes agregar más formatos, incluida la codificación de colores y la manipulación de 
cadenas, para facilitar la lectura: 


$ git for-each-ref --sort=authordate M 
--format='%(color:cyan)%(authordate: format :%m/%d/%Y %1:%M %p)%(align:25, left )% 
(color:yellow) %(authorname)%(end)%(color:reset)%(refname:strip=3)' M 
refs/remotes 


Información mostrada de ejemplo: 


01/16/2019 03:18 PM tux dev 
05/15/2022 10:35 PM agil main 


Puedes utilizar grep para obtener el nombre del autor del nombre de una rama remota: 


$ git for-each-ref --sort=authordate M 
--format='%(authorname) %(refname)' M 
refs/remotes | grep <topic_branch_name> 


Mejora tus conocimientos de las ramas en Git 


Hay matices en el funcionamiento de las ramas de Git, por ejemplo según el punto en el que 
desees bifurcar la base del código, cómo el mantenedor del repositorio gestiona las 
bifurcaciones, reorganizar, etc. Aquí hay tres artículos para leer más sobre este tema: 
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Eliminar la referencia local a una 
rama remota en Git 


Por Agil Antony 


Después de que hayas fusionado tu pull request en un servicio de Git como GitLab o GitHub 
normalmente quieres eliminar la rama específica que has creado para un tema en concreto 
para mantener un repositorio limpio. Sin embargo. Esta acción elimina únicamente la rama 
específica en el repositorio remoto. Tu repositoriolocal de Git también se debería de 
beneficiar de una limpieza rutinaria. 

Para sincronizar la información en tu repositorio local con el remoto, puedes ejecutar el 
siguiente comando git prune para eliminar la referencia local a una rama remota en tu 
repositorio local. 


Sigue estos tres simples pasos: 


1. Cambia a la rama central de tu repositorio (normalmente llamada main o master). 


$ git checkout <central_branch_name> 


2. Lista todas las ramas locales y remotas. 


$ git branch -a 


Ejemplo de salida del comando: 


4.10.Z 

* master 
remotes/mydata/4.9-stage 
remotes/mydata/4.9.z 
remotes/mydata/test-branch 


En este ejemplo, test -branch es el nombre de la rama específica creada y que ya hemos 
borrado en el repositoro remoto. 


3. Elimina la referencia local a la rama remota. 


Primero, lista todas las ramas que puedes eliminar o purgar en tu repositorio local: 


$ git remote prune origin --dry-run 
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Ejemplo del comando: 


Pruning origin 
URL: gitfWexample.com:myorg/mydata-4.10.git 
* [would prune] origin/test-branch 


A continuación, purga la referencia local a la rama remota: 


$ git remote prune origin 


Ejemplo: 


Pruning origin 
URL: gitfWexample.com:myorg/mydata-4.10.git 
* [pruned] origin/test-branch 


¡Y eso es todo! 


Manteniendo tu repositorio Git 


Mantener ordenado tu repositorio de Git puede no parecer una tarea urgente al principio, pero 
cuanto más crece un repositorio, más importante se vuelve eliminar los datos innecesarios. 
No ralentices la velocidad obligándose a cincronizar datos que ya no necesitas. 


La eliminación periódica de las referencias locales a las ramas remotas es una buena 
práctica para mantener un repositorio de Git utilizable. 
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Mi guía para utilizar el comando Git 
push de manera segura 


Por Noaa Barki 


La mayoría de las personas saben que uilizar el comando de Git push --force está 
totalmente desaconsejado y es considerado destructivo. 

Sin embargo, me pareció muy extraño poner toda mi confianza en Git con mis proyectos y al 
mismo tiempo evitar por completo el uso de uno de sus comandos populares. 


Esto me llevó a investigar por qué la gente considera que este comando es tan dañino. 
¿En primer lugar, por qué existe? ¿Y qué pasa en el repositorio de manera interna al utilizarlo? 


En este artículo, comparto mis descubrimientos para que tu también puedas comprender el 
uso y el impacto de este comando en tu proyecto, aprender nuevas alternativas más seguras 
y comprender las habilidades para restaurar una rama rota. Quizás te sorprendas de que la 
fuerza de force te acompaña. 


El comando git push 


Para comprender cómo funciona Git, hay que dar un paso atrás y examinar cómo Git 
almacena sus datos. Para Git todo se trata de commits. Un commit es un objeto que incluye 
varias claves, como una ID única, un puntero a la instantánea del contenido preparado y 
punteros a los commits que vinieron directamente antes de ese commit. 


Una rama, para el caso, no es más que un puntero a un solo commit. 
Qué hace básicamente git push: 
1. Copia todos los commits que existen en la rama local 


2. Integra los historiales reenviando la rama remota para hacer referencia al nuevo commit, 
también llamada referencia de avance rápido (Fast forward ref). 


Fast forward ref 


El avance rápido o fast forward es simplemente reenviar la referencia del commit actual de la 
rama. Git busca automáticamente una ruta lineal desde la referencia actual hasta la 
referencia de commit de destino cuando envías (push) tus cambios. 
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Si un commit antecesor existe en la rama remota, pero no en la local (alguien actualizó el 
repositorio remoto, pero las cosas aún tienen que actualizarse de manera local), Git no 
encontrará una ruta lineal entre ambos commits y el comando git push fallará. 


o t 
(master) branch (master) branch 


Remote 


(Noaa Barki, CC BY-SA 4.0) 


Puedes utilizar git rebase, git squash, y git commit --amend para alterar el historial 
de commits y volver a escribir commits enviados previamente. Pero les advierto, amigos míos, 
que estos poderosos comandos no solo alteran los commits, sino que reemplazan todos los 
commits y crean otros completamente nuevos. 


Un simple git push falla, y debes omitir la regla de "avance rápido". 
Ejecuta - -force. 


Esta opción anula la restricción de "avance rápido" y hace coincidir nuestra rama local con la 
rama remota. La opción - - force te permite ordenarle a Git que lo haga de todos modos. 


Cuando cambias el historial, vo cuando deseas enviar cambios que no son consistentes con la 
rama remota, puedes usar push --force. 
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Press ¡esc | to exit ful screen 


git commit --amend 


(master) branch (master) branch 


Remote 


= 0 $ 


(Noaa Barki, CC BY-SA 4.0) 


Imagina que Lilly y Bob son desarrolladores que trabajan en la misma rama. Lilly completó 
sus tareas y envió sus cambios al repositorio remoto de Git. Después de un tiempo, Bob 
también terminó su trabajo, pero antes de enviar sus cambios, realizó algunos cambios 
adicionales. Realizó una rebase para mantener el árbol limpio y luego usó push -- 

force para que sus cambios estuvieran en el repositorio remoto. Desafortunadamente, al no 
estar actualizado a la rama remota, Bob borró accidentalmente todos los registros de los 
cambios de Lilly. 
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Pross ¡esc | to exit ful screon 


git push --force 


(master) branch (master) branch 


Remote 


(Noaa Barki, CC BY-SA 4.0) 


Bob cometió un error muy común al utilizar la opción - - force. Bob olvidó actualizar (git 
pul1) su rama local. Con una rama a la que el usuario todavía no ha actualizado, al utilizar - - 
force causó que Git enviara los cambios de Bob sin tener en cuenta el estado de la rama 
remota, por lo que los commits se pierden. Por supuesto, no se ha perdido todo, y el equipo 
puede tomar medidas para recuperarse, pero si no se detecta, este error podría causar 
muchos problemas. 


La opción - - force tiene un pariente no tan famoso llamado —-force-with- lease, que 
hace que puedas enviar (push) con - - force y tendrás la garantía de que no sobrescribirás 
el trabajo de nadie. De manera predeterminada, - -force-with- lease evita actualizar la 
rama a menos que la rama remota de seguimiento remota y la rama remota apunten a la 
referencia del mismo commit. ¿Eso está bastante bien, verad? Pero todavía es mejor. 


Puedes especificar - -fForce-with- lease exactamente con qué commit, rama o referencia 
quieres que compare. La opción - -force-with- lease te da la flexibillidad de sobrescribir 
nuevos commits de tu rama remota mientras mantienes tu antiguo historial de commits. Es 
el mismo comando force pero con un chaleco salvavidas. 
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Guía: Cómo manejar el destructivo *--force" 


Sin duda, tu eres un desarrollador o una desarrolladora esponsable, pero apuesto que alguna 
vez te ocurrió que alguno de tus colegas de trabajo de manera accidental ejecutó un git 
push --force dentro de una rama importante en la que nadie debería meterse jamás. En 
un abrir y cerrar de ojos, el trabajo más reciente de todo el mundo se perdió. 


¡No hay necesidad de entrar en pánico! Si tienes mucha suerte, alguien más que estuviera 
trabajando con el código, descargó una versión reciente de la rama justo antes de que se 
perdiera. Si es así, todo lo que tienes que hacer es pedirle que ejecute - - force push para 
subir sus cambios más recientes. 


Pero si incluso no has tenido tanta suerte, sí has sido afortunado de encontrar este artículo. 


1. ¿Fuiste la última persona en enviar (push) el código antes 
del error? 

Lo primero, NO cierres la terminal. 

Segundo, acude a tus compañeros de trabajo y confiesa tus pecados. 


Finalmente, asegúrate de que nadie más se meta en el repositorio en los dos minutos 
siguientes, porque tienes un trabajo que hacer. 


Regresa a tu sitio. En la salida del comando que has ejecutado por error git push -- 
force busca una línea similar a esta: 


+ d02c26f..fo0f00ba [NombreDeRama] -> [NombreDeRama] (forced update) 


El primer grupo de símbolos (que parece un prefijo SHA de un commit) es la clave para 
solucionar este problema. 


Supongamos que el último commit bueno que enviaste a la rama, antes de producir el 
desastre fue el d02c26f. Tu única opción es combatir el fuego con fuego y ejecutar un push 
- - force a ese commit para situarlo en la parte superior de la rama del commit malo: 


$ git push — force origin deadbeef: [NombreDeRama] 


¡Felicidades! ¡Conseguiste solventar la situación! 
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2. De manera accidental utilicé --force push en mi 
repositorio, y quiero regresar a una versión previa. ¿Qué 
hago? 

Imagina que estás trabajando en una rama de una nueva funcionalidad. Descargaste (pull) 
algunos cambios, creaste algunos commits, realizaste parte de esa nueva funcionalidad y 
enviaste (push) tus cambios al repositorio principal. Después uniste todos los commits en 
uno solo, utilizando git rebase -i y de nuevo enviaste los cambios utilizando push - - 
force. Pero algo malo sucedió, y quieres restaurar tu rama a la que estaba antes de la 
ejecución del comando rebase -i. Una de las cosas geniales de Git es que es el mejor y 
nunca pierde datos, así que la versión del repositorio antes del comando rebase todavía 
está disponible. 


En este caso, puedes utilizar el comando git ref log que muestra un historial detallado del 
repositorio. 


Para cada “actualización” que realizaste en tu repositorio local, Git crea una entrada en un 
registo o log de referencia. El comando git ref log muestra esos logs de referencia o 

ref logs, almacenados en tu repositorio Git local. La salida del comando git 

ref log contiene todas las acciones que han cambiado las ramas y otras referencias en el 
repositorio local, incluyendo el cambio entre ramas y rebases. La parte superior y más 
reciente de la rama (llamada HEAD) es una referencia simbólica a la rama activa actual. Solo 
es una referencia simbólica ya que una rama es un puntero a un commit. 


Aquí se muestra un ref Log simple, que muestra el escenario descrito anteriormente: 


1b46bfc65e (HEAD -> test-branch) HEAD (QM (0) : rebase -i (finish): returning to 
refs/heads/test-branch 

b46bfc65e (HEAD -> test-branch) HEAD Q (1): rebase -i (squash): a 

dd7906a87 HEAD (MU (2) : rebase -i (squash): + This is a combination of 2 commits. 
a3030290a HEADC (3): rebase -i (start): checkout refs/heads/master 

O0c2d866ab HEADOf14): commit: c 

6cab968c7 HEADO (5) : commit: b 

a3030290a HEAD (M0 (6): commit: a 

c9c495792 (origin/master, origin/HEAD, master) HEADO (7): checkout: moving from 
master to test-branch 

c9c495792 (origin/master, origin/HEAD, master) HEADO (8) : pull: Fast-forward 


La notación HEADOLnúmero) es la posición de HEAD en el número de cambios, que muestra 
el número, anteriores. Así HEADO(0) es el HEAD donde HEAD está ahora y HEADO( 4) es 
HEAD hace cuatro pasos atrás. Puedes ver en el ref log mostrado, que HEADQ( 4) es donde 
necesitas restaurar la rama ya que está justo antes del rebase, y 0c2d866ab es ID del 
commit para ese commit al que regresar. 
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Así que para restaurar la rama al estado que necesitas, necesitas hacer un reset a la rama: 


$ git reset — hard HEADO(4) 


Después ya puedes volver a ejecutar force push para restaurar el repositorio a donde estaba 
anteriormente. 


Recuperación general 


En cualquier momento en el que quieras restaurar tu rama a la versión previa después de 
ejecutar push --force, sigue esta plantilla de solución de recuperación general: 


1. Obtén el ID del commit previo utilizando la terminal. 
2. Crea una rama o haz un reset a ese commit previo. 
3.Usa push --force. 


Si quieres crear una rama nueva, no olvides realizar un reset a la rama, así está sincronizada 
con el repositorio remoto ejecutando el siguiente comando: 


$ git reset --hard origin/[new-branch-name] 


3. Restaurar push --force de una rama eliminada con git fsck 
Supongamos que tienes un repositorio. 
Tuviste un desarrollador que escribió el proyecto para ti. 


El desarrollador decidió eliminar todas las ramas y ejecutar un push --force en un commit 
con el mensaje "El proyecto estaba aquí." 


El desarrollador dejó el país sin forma de contactar con él o encontarle. No tienes el código y 
nunca clonaste el repositorio en tu equipo. 


Lo primero, necesitas encontrar un commit previo. 


Desafortunadamente, en este caso, utilizar git log no ayudará porque el único commit al 
que apunta la rama es "El proyecto estaba aquí" sin ningún commit más relacionado. En este 
caso, debes encontrar commits eliminados a las que no se haya vinculado ningún commit 
secundario, rama, etiqueta u otra referencia. Afortunadamente, la base de datos de Git 
almacena estos commits huérfanos y puedes encontrarlo utilizando el comando git fsck 


git fsck --lost-found 
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Estos reciben el nombre de "dangling commits" o commits colgantes. De acuerdo a la 
documentación un simple git gc elimina esos commits colgados de más de dos semanas 
de antiguedad. En este caso todo lo que tienes son esos commits colgantes y todo lo que 
queda por hacer es encontrar el commit previo al daño y seguir los pasos de la plantilla de 
recuperación anterior. 


Ramas protegidas y revisiones de código 
Como dice el viejo dicho: 


"La diferencia entre una persona lista y una persona inteligente, es que la persona 
lista sabe cómo salir de un problema en el que una persona inteligente de primeras 
no se habría metido." 


Si quieres evitar por completo push --force, tanto como GitHub o GitLab ofrecen una 
funcionalidad muy interesante llamada Ramas protegidas o Protected Branches, que te 
permite marcar cualquier rama como protegida, así ninguna persona podrá ejecutar en ella 
push --force. 


También puedes establecer preferencias de administración para restringir los permisos. 


De manera alternativa también puedes crear Git hooks para requerir revisión del código o 
aprobación antes que cualquier persona pueda enviar (push) código a una rama importante. 


Sumario 


Con un poco de suerte, ahora entiendes cuando necesitas añadir la opción - - force y los 
riesgos que conlleva al utilizarla. Recuerda, - - Force está ahí para tí. Solo es un desvío y 
como cualquier desvío, deberías utilizarlo con cuidado. 


May the - - force be with you. (Que la fuerza te acompañe) 
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Recuperarse después de un git 
rebase fracasado con git reflog 


Por Agil Antony 


El comando git rebase te permite ajustar el historial de tu repositorio. Es una funcionalidad 
útil, pero por supuesto, siempre pueden ocurrir errores. Como suele ser el caso con Git, 
puedes reparar tu error y restaurar tu repositorio a un estado anterior. Para recuperarte de un 
rebase fracasado, utiliza el comando git reflog 


Git reflog 


Supongamos que realizas este rebase interactivo: 


$ git rebase -i HEAD-20 


En este contexto, -20 significa hacer un rebase a los últimos 20 commits. 


Desafortunadamente, en este ejemplo que hemos imaginado, de manera errónea has perdido 
algunos commits que no querías perder. Ya has completado el rebase, pero esto es Git, así 
que por supuesto que podrás recuperar tus commits perdidos. 


Revisa tu historial con reflog 


Ejecuta el comando git ref log para recopilar datos y ver un historial de tus interacciones 
con tu repositori. Este es un ejemplo para mi repositoriode demostración, sin embargo, el 
resultado podría variar dependiendo de tu repositorio actual: 


$ git reflog 

222967b (HEAD -> main) HEADOJ0): rebase (finish): returning to refs/heads/main 
222967b (HEAD -> main) HEADO(1): rebase (squash): My big rebase 

c388f0c HEADO(2): rebase (squash): + This is a combination of 20 commits 
56ee04d HEADO(3): rebase (start): checkout HEAD-20 

0a0f875 HEADO(4): commit: An old good commit 

A] 
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Encuentra el último commit correcto 


En este ejemplo, HEADO(3) representa el comienzo de tu rebase. Puedes confirmarlo porque 
su descripción es rebase (start). 


El commit justo por debajo a ese, V0a0f875 HEAD(O( 4), es la cima de la rama de Git antes de 
que ejecutaras de manera incorrecta tu rebase. Dependiendo de cómo es de antiguo o de 
activo tu repositorio, puede haber más líneas por debajo de esta, pero asumamos que este es 
el commit que quieres restaurar, 


Restaurar el commit 


Para recuperar el commit que eliminaste de manera accidental y todos los commits 
relacionados, incluyendo esos que de manera accidental eliminaste, utiliza git checkout. 
En este ejemplo, HEADO( 4) es el commit que necesitas restaurar, así que es en ese en el que 
necesitas ejecutar el siguiente comando: 


$ git checkout HEADO(4) 


Con tu commit correcto restaurado, puedes crear una nueva rama utilizando git checkout 
-b <nombre_de_ la_rama> como es habitual. Reemplaza <nombre_de_ la_rama> con el 
nombre de la rama que desees ponerle, por ejemplo rama - test. 


Control de versión con Git 


El propósito de Git es realizar un seguimiento de las versiones, y su configuración 
predeterminada suele ser conservar la mayor cantidad posible de datos sobre tu trabajo. 
Aprender a usar los nuevos comandos de Git hace que muchas de sus funciones más 
potentes estén disponibles y protege tu trabajo. 


Creative Commons Attribution Share-alike 4.0 51 


Echar un vistazo a un repositorio Git 
con rev-parse 


Por Seth Kenlon 


Utilizo mucho Git. De hecho, probablemente haya un argumento de que a veces lo uso mal. 
Utilizo Git para mi sitio web, e incluso mi calendario personal. 

Para hacer un mal uso de Git, escribo muchos hooks para Git. Uno de mis subcomandos 
favoritos de Git es rev-parse, porque cuando estás creando scripts con Git, necesitas 
información sobre tu repositorio Git tan a menudo como necesitas información de él. 


Obteniendo el directorio del nivel superior 


Para Git, no hay directorios más atrás que su propia carpeta de nivel superior. Eso es en parte 
lo que hace posible mover un directorio Git desde, por ejemplo, tu equipo a una memoria USB 
o un servidor sin pérdida de funcionalidad. 


Git solo conoce el directorio que contiene el directorio oculto . git y cualquier carpeta 
rastreada que esté por debajo de esta. La opción - -show-toplevel muestra el directorio 
raíz de du repositorio Git actual. Este es el lugar donde todo comienza, al menos para Git. 


Aquí hay un ejemplo obvio de cómo podrías usarlo: 


$ cd -/example.git 
$ git rev-parse --show-toplevel 
/home/seth/example.git 


Se vuelve más útil cuando estás más ahondas en tu repositorio de Git. No importa dónde 
recales dentro de un repositorio, rev-parse --show-toplevel siempre conoce cual es el 
directorio raíz del repositorio Git: 


$ cd -/example.git/foo/bar/baz 
$ git rev-parse --show-toplevel 
/home/seth/example.git 


De manera similar, puede obtener un puntero a lo que hace que ese directorio sea el nivel 
superiorl: la carpeta oculta .git 


$ git rev-parse --git-dir 
/home/seth/example.com/.git 
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Encuentra tu camino a casa 


La opción - - show-cdup te dice (a ti o probablemente a un script) exactamente cómo llegar 
hasta esa carpeta superior de tu directorio de trabajo actual. Es más sencillo que tratar de 
aplicar ingeniería inversa a la salida del comando anterior -show-toplevel, y es algo que 
se puede aplicar en cualquier sistema aunque no tenga los comandos pushd y popd. 


$ git rev-parse --show-cdup 
A 


Curiosamente, puedes engañar a - - show-cdup, si quieres. Utiliza la opción - -prefix para 
falsificar el directorio desde el que estás haciendo la consulta: 


$ cd -/example.git/foo/bar/baz 
$ git rev-parse --prefix /home/seth/example.git/foo --show-cdup 
ET 


Ubicación actual 

Si necesitas confirmación desde dónde se está ejecutando un comando, puedes utilizar las 
opciones - -is-inside-work-treeo --is-inside-git-dir. Estas opciones 
devuelven un valor booleano basado en el directorio de trabajo actual: 


$ pwd 

.git/hooks 

$ git rev-parse --is-inside-git-dir 
true 


$ git rev-parse --is-inside-work-tree 
false 


Scripts de Git 


El subcomando rev-parse puede ser muy útil. No es algo que la mayoría de la gente pueda 
necesitar en su día a día. Sin embargo, si escribes muchos hooks de Git o usas mucho Git 
mediante scripts, puede ser el subcomando de Git que siempre quisiste conocer, pero no 
sabías que lo querías. 


Pruébelo la próxima vez que invoques a Git en un script. 
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